Lean from the Trenches
- Downloads：6926
- Type：Epub+TxT+PDF+Mobi
- Create Date：2021-08-08 08:54:53
- Update Date：2025-09-06
- Status：finish
- Author：Henrik Kniberg
- ISBN：1934356859
- Environment：PC/Android/iPhone/iPad/Kindle
- Download
Summary
Lean from the Trenches is all about actual practice。
Find out how the Swedish police combined XP， Scrum， and Kanban in a 60-person project。 From start to finish， you'll see how to deliver a successful product using Lean principles。
We start with an organization in desperate need of a new way of doing things and finish with a group of sixty， all working in sync to develop a scalable， complex system。 You'll walk through the project step by step， from customer engagement， to the daily "cocktail party，" version control， bug tracking， and release。 In this honest look at what works--and what doesn't--you'll find out how to:
Make quality everyone's business， not just the testers。 Keep everyone moving in the same direction without micromanagement。 Use simple and powerful metrics to aid in planning and process improvement。 Balance between low-level feature focus and high-level system focus。
You'll be ready to jump into the trenches and streamline your own development process。
Contents
Foreword
Preface
PART I: HOW WE WORK
1。 About the Project
1。1 Timeline 5
1。2 How We Sliced the Elephant 6
1。3 How We Involved the Customer 7
2。 Structuring the Teams
3。 Attending the Daily Cocktail Party
3。1 First Tier: Feature Team Daily Stand-up
3。2 Second Tier: Sync Meetings per Specialty
3。3 Third Tier: Project Sync Meeting
4。 The Project Board
4。1 Our Cadences
4。2 How We Handle Urgent Issues and Impediments
5。 Scaling the Kanban Boards
6。 Tracking the High-Level Goal
7。 Defining Ready and Done
7。1 Ready for Development
7。2 Ready for System Test
7。3 How This Improved Collaboration
8。 Handling Tech Stories
8。1 Example 1: System Test Bottleneck
8。2 Example 2: Day Before the Release
8。3 Example 3: The 7-Meter Class
9。 Handling Bugs
9。1 Continuous System Test
9。2 Fix the Bugs Immediately
9。3 Why We Limit the Number of Bugs in the Bug Tracker
9。4 Visualizing Bugs
9。5 Preventing Recurring Bugs
10。 Continuously Improving the Process
10。1 Team Retrospectives
10。2 Process Improvement Workshops
10。3 Managing the Rate of Change
11。 Managing Work in Progress
11。1 Using WIP Limits
11。2 Why WIP Limits Apply Only to Features
12。 Capturing and Using Process Metrics
12。1 Velocity （Features per Week）
12。2 Why We Don’t Use Story Points
12。3 Cycle Time （Weeks per Feature）
12。4 Cumulative Flow
12。5 Process Cycle Efficiency
13。 Planning the Sprint and Release
13。1 Backlog Grooming
13。2 Selecting the Top Ten Features
13。3 Why We Moved Backlog Grooming Out of the Sprint Planning Meeting
13。4 Planning the Release
14。 How We Do Version Control
14。1 No Junk on the Trunk
14。2 Team Branches
14。3 System Test Branch
15。 Why We Use Only Physical Kanban Boards
16。 What We Learned
16。1 Know Your Goal
16。2 Experiment
16。3 Embrace Failure
16。4 Solve Real Problems
16。5 Have Dedicated Change Agents
16。6 Involve People
PART II: A CLOSER LOOK AT THE TECHNIQUES
17。 Agile and Lean in a Nutshell
17。1 Agile in a Nutshell
17。2 Lean in a Nutshell
17。3 Scrum in a Nutshell
17。4 XP in a Nutshell
17。5 Kanban in a Nutshell
18。 Reducing the Test Automation Backlog
18。1 What to Do About It
18。2 How to Improve Test Coverage a Little Bit Each Iteration
18。3 Step 1: List Your Test Cases
18。4 Step 2: Classify Each Test
18。5 Step 3: Sort the List in Priority Order
18。6 Step 4: Automate a Few Tests Each Iteration
18。7 Does This Solve the Problem？
19。 Sizing the Backlog with Planning Poker
19。1 Estimating Without Planning Poker
19。2 Estimating with Planning Poker
19。3 Special Cards
20。 Cause-Effect Diagrams
20。1 Solve Problems， Not Symptoms
20。2 The Lean Problem-Solving Approach: A3 Thinking
20。3 How to Use Cause-Effect Diagrams
20。4 Example 1: Long Release Cycle
20。5 Example 2: Defects Released to Production
20。6 Example 3: Lack of Pair Programming
20。7 Example 4: Lots of Problems
20。8 Practical Issues: How to Create and Maintain the Diagrams
20。9 Pitfalls
20。10 Why Use Cause-Effect Diagrams？
21。 Final Words
A1。 Glossary: How We Avoid Buzzword Bingo
Index
Find out how the Swedish police combined XP， Scrum， and Kanban in a 60-person project。 From start to finish， you'll see how to deliver a successful product using Lean principles。
We start with an organization in desperate need of a new way of doing things and finish with a group of sixty， all working in sync to develop a scalable， complex system。 You'll walk through the project step by step， from customer engagement， to the daily "cocktail party，" version control， bug tracking， and release。 In this honest look at what works--and what doesn't--you'll find out how to:
Make quality everyone's business， not just the testers。 Keep everyone moving in the same direction without micromanagement。 Use simple and powerful metrics to aid in planning and process improvement。 Balance between low-level feature focus and high-level system focus。
You'll be ready to jump into the trenches and streamline your own development process。
Contents
Foreword
Preface
PART I: HOW WE WORK
1。 About the Project
1。1 Timeline 5
1。2 How We Sliced the Elephant 6
1。3 How We Involved the Customer 7
2。 Structuring the Teams
3。 Attending the Daily Cocktail Party
3。1 First Tier: Feature Team Daily Stand-up
3。2 Second Tier: Sync Meetings per Specialty
3。3 Third Tier: Project Sync Meeting
4。 The Project Board
4。1 Our Cadences
4。2 How We Handle Urgent Issues and Impediments
5。 Scaling the Kanban Boards
6。 Tracking the High-Level Goal
7。 Defining Ready and Done
7。1 Ready for Development
7。2 Ready for System Test
7。3 How This Improved Collaboration
8。 Handling Tech Stories
8。1 Example 1: System Test Bottleneck
8。2 Example 2: Day Before the Release
8。3 Example 3: The 7-Meter Class
9。 Handling Bugs
9。1 Continuous System Test
9。2 Fix the Bugs Immediately
9。3 Why We Limit the Number of Bugs in the Bug Tracker
9。4 Visualizing Bugs
9。5 Preventing Recurring Bugs
10。 Continuously Improving the Process
10。1 Team Retrospectives
10。2 Process Improvement Workshops
10。3 Managing the Rate of Change
11。 Managing Work in Progress
11。1 Using WIP Limits
11。2 Why WIP Limits Apply Only to Features
12。 Capturing and Using Process Metrics
12。1 Velocity （Features per Week）
12。2 Why We Don’t Use Story Points
12。3 Cycle Time （Weeks per Feature）
12。4 Cumulative Flow
12。5 Process Cycle Efficiency
13。 Planning the Sprint and Release
13。1 Backlog Grooming
13。2 Selecting the Top Ten Features
13。3 Why We Moved Backlog Grooming Out of the Sprint Planning Meeting
13。4 Planning the Release
14。 How We Do Version Control
14。1 No Junk on the Trunk
14。2 Team Branches
14。3 System Test Branch
15。 Why We Use Only Physical Kanban Boards
16。 What We Learned
16。1 Know Your Goal
16。2 Experiment
16。3 Embrace Failure
16。4 Solve Real Problems
16。5 Have Dedicated Change Agents
16。6 Involve People
PART II: A CLOSER LOOK AT THE TECHNIQUES
17。 Agile and Lean in a Nutshell
17。1 Agile in a Nutshell
17。2 Lean in a Nutshell
17。3 Scrum in a Nutshell
17。4 XP in a Nutshell
17。5 Kanban in a Nutshell
18。 Reducing the Test Automation Backlog
18。1 What to Do About It
18。2 How to Improve Test Coverage a Little Bit Each Iteration
18。3 Step 1: List Your Test Cases
18。4 Step 2: Classify Each Test
18。5 Step 3: Sort the List in Priority Order
18。6 Step 4: Automate a Few Tests Each Iteration
18。7 Does This Solve the Problem？
19。 Sizing the Backlog with Planning Poker
19。1 Estimating Without Planning Poker
19。2 Estimating with Planning Poker
19。3 Special Cards
20。 Cause-Effect Diagrams
20。1 Solve Problems， Not Symptoms
20。2 The Lean Problem-Solving Approach: A3 Thinking
20。3 How to Use Cause-Effect Diagrams
20。4 Example 1: Long Release Cycle
20。5 Example 2: Defects Released to Production
20。6 Example 3: Lack of Pair Programming
20。7 Example 4: Lots of Problems
20。8 Practical Issues: How to Create and Maintain the Diagrams
20。9 Pitfalls
20。10 Why Use Cause-Effect Diagrams？
21。 Final Words
A1。 Glossary: How We Avoid Buzzword Bingo
Index
Reviews
Fritz
，
Entry level。 Good， but no surprises。
Marc Min
，
A concrete case study of how a team of 60 transferred themselves and lived in an Agile delivery model。 I like Hendrik’s written style being practical and using simple languages。
shiva kumar
，
A case study of PUST software builds for Swedish police using Agile。 For me the biggest take was on defining "Ready and Done" and you don't need fancy software to implement to follow agile。 A good quick read for the beginner。 A case study of PUST software builds for Swedish police using Agile。 For me the biggest take was on defining "Ready and Done" and you don't need fancy software to implement to follow agile。 A good quick read for the beginner。 。。。more
Eileen Dominic
，
I am not a programmer， but work fairly closely with our small company's engineering team。 This was quick， accessible， and helpful read。 Some of the technical stuff was just a little bit over my head or not directly relevant to my role， but it all helped me understand our planning and release processes better and gave me some ideas for better optimizing my team's projects and processes using Trello （a digital Kanban board tool）。 I am not a programmer， but work fairly closely with our small company's engineering team。 This was quick， accessible， and helpful read。 Some of the technical stuff was just a little bit over my head or not directly relevant to my role， but it all helped me understand our planning and release processes better and gave me some ideas for better optimizing my team's projects and processes using Trello （a digital Kanban board tool）。 。。。more
Federico Fregosi
，
Really hands on but nothing new under the sun here
Igor Đukić
，
Very concise book with practical examples and a lot of explained techniques。 Great summaries for lean， agile， scrum， xp， kanban。 Highly recommended。 - Know your goal - Experiment - Embrace failure- Solve real problems- Have dedicated change agent- Involve people
Jakub
，
Best agile-like book i had a chance to read。 It's not a book for religious people that think Scrum is only when its 100% Scrum and when we have XP its XP。。。 Its a book about practice， real-life example and how agile is agile。That by driving a change by a need can lead to optimized version of agile for the current team， project， or company。 And that we should just not blindly follow stupid rules when they are stupid。 Charts？ the heck with them if they are not providing value。 You can't do X？ why？ Best agile-like book i had a chance to read。 It's not a book for religious people that think Scrum is only when its 100% Scrum and when we have XP its XP。。。 Its a book about practice， real-life example and how agile is agile。That by driving a change by a need can lead to optimized version of agile for the current team， project， or company。 And that we should just not blindly follow stupid rules when they are stupid。 Charts？ the heck with them if they are not providing value。 You can't do X？ why？ if it works and it helps I can。Highly recommended for anyone even not it related people。 Books show how agile can help manage process of change and it's adaptable to current needs and requirements。 。。。more
Samuel Casanova
，
Poca información realmente nueva o reveladora。 Supongo que los años que tiene ya el libro no le favorecen。
Romain
，
Ce livre est écrit par un coach agile – n’arrêtez pas la lecture de cet article tout de suite， attendez de lire la suite。 Il s’agit d’un ponte dans le domaine Henrick Kniberg。 Comme l’indique la mention du titre From the Trenches il n’est pas question de nous abreuver de théories – et de techniques de collage de Post-It， oui ça existe – mais de nous faire vivre de l’intérieur l’organisation et la méthodologie mises en oeuvre dans le cadre d’un gros projet mené， pendant 3 ans， par la police suéd Ce livre est écrit par un coach agile – n’arrêtez pas la lecture de cet article tout de suite， attendez de lire la suite。 Il s’agit d’un ponte dans le domaine Henrick Kniberg。 Comme l’indique la mention du titre From the Trenches il n’est pas question de nous abreuver de théories – et de techniques de collage de Post-It， oui ça existe – mais de nous faire vivre de l’intérieur l’organisation et la méthodologie mises en oeuvre dans le cadre d’un gros projet mené， pendant 3 ans， par la police suédoise afin de se doter d’un puissant logiciel qui devrait – on ne sait jamais avec l’informatique – leur permettre d’améliorer le coeur de leur activité – la rédaction des procès verbaux。 Le sujet ne fait pas vraiment rêver， mais bon， j’adore ces histoires industrielles， je trouve qu’elles sont toujours riches d’enseignements。 Pour les amateurs， je pense à- Dreaming in Code qui raconte l’histoire d’un projet open source，- The Goal qui est un roman graphique illustrant l’optimisation d’une usine，- The Phoenix Project qui en est le digne successeur。Ici， il s’agit avant tout d’un livre technique qui ne met pas en oeuvre les artifices d’un roman， mais qui s’attache à exploiter ce retour d’expérience pour en extraire les recettes méthodologiques qui ont contribuées à son succès。Au centre de ce dispositif il me semble qu’il y a l’organisation autour du Kanban qui a été particulièrement travaillée pour aboutir à un résultat séduisant qui devrait pouvoir être réutilisé sans peine dans le cadre d’un autre projet informatique。 La démarche de mise en oeuvre de la méthode est elle aussi fondamentale。 On voit que la méthode a été mise au service du travail à réaliser et non l’inverse。 Elle a donc servis de canevas， de base ou de référence – selon comment on souhaite nommer les choses – mais a été en permanence remaniée， corrigée et adaptée pour coller au mieux au besoin du projet et de ses intervenants。 Il illustre également d’autres éléments plus classiques comme limiter le travail en cours （WIP pour Work In Progress et le fameux “Stop starting， start finishing”）， mais toujours avec une approche plus pragmatique que dogmatique – en évitant toujours d’appliquer la méthodologie uniquement pour l’appliquer。 Cette approche pragmatique se retrouve aussi par exemple dans la définition des métriques pour le suivi du projet qui se trouvent réduits à la substantifique moelle – less is more- Velocity in features per week: Pas besoin d’être plus précis。- Cycle time in weeks per feature: Combien de temps requiert la livraison d’une fonctionnalité。Il est intéressant d’observer que le temps nécessaire à la fourniture de bout en bout d’une fonctionnalité est souvent 5 à 10 fois le temps nécessaire à sa mise en oeuvre （par exemple si une fonctionnalité requiert 5 jours de travail il faudra de 25 à 50 jours calendaires pour la livrer au client final）。 Grâce à ces mesures il est donc possible de mettre en évidences les goulets – ou goulots – d’étranglement。 Ces mesures sont inspirées de la loi Little faisant partie de la théorie des files d’attentes。Enfin il prouve que l’agilité ne doit pas faire oublier l’essentiel comme la structuration des équipes ou le respect des différentes phases de développement[1]。 Une lecture éclairante pour soit se familiariser ou soit prendre du recul avec les méthodes agiles en bénéficiant d’un vrai retour d’expérience。----[1] Le livre se termine par des rappels méthodologiques concernant les principaux éléments méthodologiques abordés， l’une des plus intéressantes étant le diagramme de cause à effet ou A3 thinking。Également publié sur mon blog。 。。。more
Greg G
，
Lots of good tips and examples and reading about real world challenges and how they resolved them。
David Dikman
，
Light and useful readJust like with his previous success Scrum from the trenches this book gives you a practical example of how to approach Kanban。 It's written well but informally making it a light and instructive read。As it's not a huge investment and provides good practical experience to draw from， a definite recommend Light and useful readJust like with his previous success Scrum from the trenches this book gives you a practical example of how to approach Kanban。 It's written well but informally making it a light and instructive read。As it's not a huge investment and provides good practical experience to draw from， a definite recommend 。。。more
Bartosz Pranczke
，
It was a great read。 Zero theory， just a case study why and how things from Lean and Agile were implemented in managing a big project。 High signal to noise ratio。
Alex Vasilenko
，
Despite being short and simple the book is really great for both starters of Agile and people who are practicing it and looking for more answers。 First part consists of 1 big example running a project under certain circumstances。 For starters it helps to grasp a picture what Agile is and for practices - gives broader spectrum of tools/techniques to apply。 Second part is short and consists of theory of what Agile is。 Most probably would be useful only for starters。
Emre Sevinç
，
Writing a book on software project management methodologies is not something to be taken lightly。 One runs the risk of not satisfying anyone while trying to cater to the wishes of everyone。 Even though the title and cover pages are 100% buzzword compliant， which is a warning sign by itself， Henrik Kniberg seems to have achieved a satisfying result in his book 'Lean from the Trenches: Managing Large-Scale Projects with Kanban'。The good partsThe book is short。 In 150 pages you cannot go into detai Writing a book on software project management methodologies is not something to be taken lightly。 One runs the risk of not satisfying anyone while trying to cater to the wishes of everyone。 Even though the title and cover pages are 100% buzzword compliant， which is a warning sign by itself， Henrik Kniberg seems to have achieved a satisfying result in his book 'Lean from the Trenches: Managing Large-Scale Projects with Kanban'。The good partsThe book is short。 In 150 pages you cannot go into details and start theoretizing， and this is good because Kniberg promises to do one thing well and he delivers it: A case study of a 60-person software development team who used a mixture of Kanban， Agile （Scrum） and XP methodologies。His explanations are generally clear and his definitons are sharp enough for practical purposes。 He does not preach and never takes a 'here is the absolute truth， use it as it is' approach。 He tells the his team's story and does not hide the parts that are still evolving。The chapter 'Agile and Lean in a Nutshell' is one of the best chapters。 In only 10 pages， this chapter succeeds to provide the reader with the essence of those methodologies。 The subsection 'One Day in Kanban Land' is a very nice example of using simple visualizations and storytelling to explain a concept in very concrete terms。The core ideas such as 'why WIP （Work In Progress） should be limited'， 'how to reduce the test automation backlog'， and 'cause effect diagrams' are very well explained。 I have also liked the chapter where the author justifies their use of physical Kanban boards and how they scaled those boards to 60 people。The bad partsThe book is short。 Do not expect to find detailed theoretical and historical discussions on the different methodologies mentioned。 You will definitely need at least a few other books to fill in the gaps。At that page count， it is probably normal that the author did not go into the direction of deeper analysis， and especially talk about the details of problems they have solved， as well as other challenges he and his team encountered。 Nevertheless， I believe enriching the book in that direction would only prove to add more value to the book。The photographs， screenshots， diagrams， and index could be better， in color and titled。 In its current form， they help to form the impression that the book has been very much rushed into production。 That may be fine in terms of lean book production， or Agile Book Writing， or using Kanban to write a book， but the readers deserve more than that when they hold a book in its final form。 Moreover， simply dropping footnotes at the end of a page and not creating a short References chapter is annoying because it prevents you from easily skimming those resources。ConclusionAs a case study of a successful， real-life software development project that utilized Lean， Agile and Kanban， this is a book with very valuable lessons。 It will probably be more helpful for decision makers such as software team leads and/or software project managers。 It is not the reference for any of the software methodologies， but it stands as a very good evidence describing the daily operations of a relatively large team。 。。。more
Muhammad Ali
，
A good book to understand KANBAN for starters， tells you how KANBAN can help you in different stages of the SDLC。 You may want to have this as a KANBAN reference book。
Marcin
，
I've liked it mainly for two reasons:1） It's not 'religious' or black and white only。 We can read about different methodologies or techniques for project management， but nothing is treated as a silver bullet。 Everything has pros and cons and author states it clearly2） It has 'this worked for us because' parts。 There are many books that say you should do XYZ because it's good。 But they don't try enough to explain why。 Here you have a story of existing project。 You can read what worked， what not a I've liked it mainly for two reasons:1） It's not 'religious' or black and white only。 We can read about different methodologies or techniques for project management， but nothing is treated as a silver bullet。 Everything has pros and cons and author states it clearly2） It has 'this worked for us because' parts。 There are many books that say you should do XYZ because it's good。 But they don't try enough to explain why。 Here you have a story of existing project。 You can read what worked， what not and how they have tweaked things along the way。 。。。more
Nathalie Karasek
，
Cool case study written in quite narrative style。 Hands-on and useful！ Love it！
Farhodjon
，
A good practical book from Henrik Knieberg （who has a lot of knowledge on Agile） how they've used Kanban for a big project。 Recommended to people who like Kanban。 A good practical book from Henrik Knieberg （who has a lot of knowledge on Agile） how they've used Kanban for a big project。 Recommended to people who like Kanban。 。。。more
Valentin
，
among all the books on lean，xp and scrum this is the most down to earth book i've read。there are a lot of examples and experiences shared by the author and these are helping a lot to understand how things are working in practice。i highly recommend it to anyone who is just starting to learn about these topics or wants to improve his practice of them。 among all the books on lean，xp and scrum this is the most down to earth book i've read。there are a lot of examples and experiences shared by the author and these are helping a lot to understand how things are working in practice。i highly recommend it to anyone who is just starting to learn about these topics or wants to improve his practice of them。 。。。more
Pradeep Mishra
，
This is a nice book on how to put agile principles， specially Kanban， into software development practice。 Content is very pragmatic and easy read。 Highly recommended and can be referred again and again。
Paco Orozco
，
Very practical， but the focus isn't clear to me。 It's a case about success with kanban and scrum in a big （very big） project Very practical， but the focus isn't clear to me。 It's a case about success with kanban and scrum in a big （very big） project 。。。more
Vatroslav Mileusnić
，
A useful case study on implementing Kanban into a software development company。 Holds many advices。
Sebastian Gebski
，
By far my most favorite kind of agile-related books。 Maybe even a example of the only kind of agile books worth reading （once you get through classics）。Shortly speaking， this whole book is a case - a story of particular endeavor Henrik took part in。 Some may call it project， it's good enough approximation。 Henrik has sliced the whole thing into chapters about organization， most important challenges， process， learnings， etc。 All the chapters are very "to-the-point"， zero bullshit & contain some a By far my most favorite kind of agile-related books。 Maybe even a example of the only kind of agile books worth reading （once you get through classics）。Shortly speaking， this whole book is a case - a story of particular endeavor Henrik took part in。 Some may call it project， it's good enough approximation。 Henrik has sliced the whole thing into chapters about organization， most important challenges， process， learnings， etc。 All the chapters are very "to-the-point"， zero bullshit & contain some actual project visuals to help you get the essence。Henrik seems very honest - I mean， I can't verify whether things he describes happened in exactly the written way， but what I can say is that:* he doesn't pretend they did anything in the most zealous， "evangelic" way* he emphasizes that mechanism that have been worked out were the result of evolution， not a generic prescriptionOn of key points of this book （IMHO） is to show that you'll get the best results if you truly understand the meaning & true reasons behind lean & agile values， not just frameworks & methods。 Tailing， customizing & thinking on your own are much more important than having "100% of Scrum in Scrum"。Decent read， if you're really into the topic。 。。。more
bm
，
Excellent book describing a real life project。 This book is full of good ideas， and gives explanations for why those ideas work。 I can see how many of these concepts and ways of working could be applied to projects that I work on。 A lot of food for thought。
Simón
，
This book gives a great insight on how to run a project in an agile way: I recommend reading it while taking notes on what to apply to your projects。 It covers a project for the Swedish police where a large-ish team of 60+ people were able to deliver a project changing how the police would do arrests on the go， from the laptops in their cars。 They would do this using Kanban and a set of multiple physical whiteboards， together with following a series of good practices。There were a number of thing This book gives a great insight on how to run a project in an agile way: I recommend reading it while taking notes on what to apply to your projects。 It covers a project for the Swedish police where a large-ish team of 60+ people were able to deliver a project changing how the police would do arrests on the go， from the laptops in their cars。 They would do this using Kanban and a set of multiple physical whiteboards， together with following a series of good practices。There were a number of things that I didn't like: 1。 The agile coach writing the book arrived late into the project。 While this doesn't invalidate his reasonings， it weakens them a bit2。 He is a clear advocate of collocation。 I agree that collocation can be beneficial， but at this point and in this field， working remotely should be a valid choice3。 The size of the teams covered in this book is quite large， 60+ if I recall correctly。 Adapting this into smaller teams could still work， but won't match 100%4。 The book covers a project developed for a known， internal customer: the Swedish police。 In my experience， it is easier to deal with internal customers， while doing in-house development than with regular external customers5。 The writer proposes not tracking bugs， and instead fixing them ad-hoc， as part of the feature development。 He also proposes dropping bugs if there are too many。 While I agree with closing bugs as WONTFIX in order to prioritise work， there should be very good reasons for thatThere were many great tips:1。 Engage， have a goal。 If the goal is unrealistic， people will disassociate themselves to avoid failure。 This is so true！ Having impossible goals is one of the best ways to kill morale。2。 Come up with real actions to reach these goals （and no: working longer hours or working harder doesn't count）。3。 Continuous testing！ This is a must。4。 Automate testing to save time when testing time grows too long。5。 Use cards and point assignment when doing retrospective （e。g。 every person is allowed to assign 3 dots。 This is a good way to prioritise）。6。 Process improvement proposal。 This was a great idea。 Basically the team should feel encouraged to come up with proposals， but these proposals should make clear what they are addressing， what they are fixing， and how they are doing it。7。 Measure velocity and cycle time。 This is one way having a healthy Kanban can allow you to plan releases and estimate when a feature will be ready。8。 Backlog grooming: spending time （project leader & product owner） dropping / prioritising the backlog items， deciding which ones should be handled next。 。。。more
John
，
The book is a 100pp case study of a software project for the Swedish police， followed by some brief chapters on a number of concrete techniques。What is great about the book is that Kniberg will steal bits from all of the methodologies he knows （Scrum， XP， Kanban， etc。） to "get it done。" On a number of occasions， he says （more or less）: "Well， I think we can improve that eventually。" For a software project methodology book， it is remarkably open。 It is， therefore， a pure version of the Scrum mant The book is a 100pp case study of a software project for the Swedish police， followed by some brief chapters on a number of concrete techniques。What is great about the book is that Kniberg will steal bits from all of the methodologies he knows （Scrum， XP， Kanban， etc。） to "get it done。" On a number of occasions， he says （more or less）: "Well， I think we can improve that eventually。" For a software project methodology book， it is remarkably open。 It is， therefore， a pure version of the Scrum mantra: "Inspect and adapt。"A few specific things: Describes a two-tier system for managing deliverables; computes velocity not based on points but on delivered features; talks about the necessity of having "slack" so that you can respond to urgent tasks。About my only reservation is that in 2016 this book from 2011 is a wee bit dated; for instance， most teams I know are delivering software every day， and not at the tempo of a month or two as described in this book。 But if you're reading the book now， you're probably cool with that。 。。。more
Manas Saloi
，
Awesome good on Kanban method（agile dev）。 If you are a project manager this book will be really helpful。
Patrik Mihalčin
，
Great book from Henrik。 Finally the one which explains agile practices in interesting way and how they did it。 I also like Spotify engineering culture Henrik described here: https://labs。spotify。com/2014/03/27/s。。。 & https://labs。spotify。com/2014/09/20/s。。。 Great book from Henrik。 Finally the one which explains agile practices in interesting way and how they did it。 I also like Spotify engineering culture Henrik described here: https://labs。spotify。com/2014/03/27/s。。。 & https://labs。spotify。com/2014/09/20/s。。。 。。。more
Tomas Systecon
，
Hands on experience in how to apply Lean to a real world development project。
Daniel St john
，
Some good ideasThe book is written in a way that's easy to understand。 It has some good ideas for sure， however I see potential gaps and pitfalls with the approach if done on large complex projects with distributed teams。 The author makes a good point that companies shouldn't just copy what they did because there is no one size fits all。 Some good ideasThe book is written in a way that's easy to understand。 It has some good ideas for sure， however I see potential gaps and pitfalls with the approach if done on large complex projects with distributed teams。 The author makes a good point that companies shouldn't just copy what they did because there is no one size fits all。 。。。more
Reference
google book https://www.google.com/search?tbm=bks&q=Lean from the Trenches
hathitrust digital library https://babel.hathitrust.org/cgi/ls?q1=Lean from the Trenches&field1=ocr&a=srchls&ft=ft&lmt=ft